1. Field of the Invention
The present invention relates to a method, system, and program for managing metadata for primary and secondary storage locations subject to a copy relationship.
2. Description of the Related Art
Data backup systems can provide continuous availability of production data in the event of a sudden catastrophic failure at a single point in time or data loss over a period of time. In one such system, production data is mirrored from a local site to a remote site which may be separated geographically by several miles from the local site. Such dual, mirror or shadow copies are typically made in a secondary storage device at the remote site, as the application system is writing new data to a primary storage device usually located at the local site. Different copy technologies may be used for maintaining remote copies of data at a secondary site, such as International Business Machine Corporation's (“IBM”) Metro Mirror Peer to Peer Remote Copy (PPRC), Extended Remote Copy (XRC), Coupled XRC (CXRC), Global Copy, and Global Mirror Copy.
In data mirroring systems, data is typically maintained in volume pairs, comprising a primary volume in a primary storage device and a corresponding secondary volume in a secondary storage device that includes an identical copy of the data maintained in the primary volume. The primary and secondary volumes are identified by a copy relationship. Primary and secondary storage controllers may be used to control access to the primary and secondary storage devices.
In the International Business Machine Corporation's (“IBM”) Global Mirror, data is asynchronously copied from the primary storage site to the secondary storage site. Data may be copied in consistency groups, such that the second copy at the secondary site is consistent as of a point-in-time to a first copy of the data at the primary site. In a consistency group, the order of dependent writes is preserved in the copying of the data.
The second copy, at the secondary site, may be copied to a target copy of the data at the secondary site using a point-in-time (“PiT”) copy techniques, such as the IBM FlashCopy® (FlashCopy is a registered trademark of IBM). In this way the second copy at the secondary site becomes the source data for the PiT copy to the target copy which is typically on the same storage as the second copy.
Customers that want to create additional copies of the target data of the target copy at the secondary site, may perform a fast reverse restore operation, where replication from the primary to the secondary site is suspended and a reverse FlashCopy is made from the target copy back to the second copy, wiping out any newer data received at the second copy since the point-in-time of the Flashcopy. After the reverse FlashCopy is made back to the second data copy, the customer may then make additional copies from the reversed second data copy.
Copy services Flashcopy, frequently use various types of bitmaps stored in metadata. One such bitmap is the source bitmap and another is the target bitmap. For example, a target bitmap typically includes a bit for each track of the second copy in the secondary storage location that storage controllers are to copy over to a corresponding track of the target copy of the secondary storage location of a copy relationship. Thus, the target bitmap indicates a backlog of tracks waiting to be copied. The source bitmap is used when reversing a FlashCopy relationship. The source bitmap indicates a backlog of tracks to be copied from the target copy back to the second copy.
To update the bits of a bitmap, a metadata track of the bitmap stored in the storage may be staged into a cache, and bits of the bitmaps may be set or cleared as appropriate to indicate the status of write operations to be performed or to indicate write operations already completed, as appropriate. Once the track of the bitmap has been updated, it may be written to the data storage.
In the event that the bitmap metadata track in the cache might be lost due to a power failure or other failure event before it can be written to the storage, entries may be made in a journal to record the updates to the bitmap. Once a track of bitmap metadata is successfully written from cache to the storage, the corresponding entry in the journal may be discarded. However, should writing of the track of bitmap from cache fail, the updates to that track of bitmap metadata may be recovered from the corresponding entries of the journal and stored in the storage. The journal is frequently maintained in nonvolatile memory so that the data stored in the journal may be maintained notwithstanding losses in power.
In some systems, a command such as the IBM Establish Fast Reverse Restore (FRR) command may be used to reverse a local copy relationship so that the original target is now the source and the original source is now the target. All modified tracks on the original source volume since the last consistency group was achieved may be restored by copying back those tracks from the original target back to the original source.
The Establish FRR command further provides for inverted copying of the bits of the original target bitmap into the original source bitmap which becomes the new target bitmap. That is, the bits of the original target bitmap are inverted and the inverted bits are copied into the original source bitmap. This bitmap metadata processing is typically done sequentially on a track by track basis, for each track of the bitmaps in sequence. Thus, for each metadata track of a bitmap, a track of the original source bitmap is staged into cache, and the bits of the original target are inverted copied into the track of the original source bitmap. The original source bitmap track containing the inverted bits of the original target track is synchronously written from cache into storage. Each track containing the inverted bits is written synchronously with the sequential processing of the tracks of the bitmap. Thus, the inverted copy processing of the tracks of the bitmap is done on a track by track basis such that the track containing the inverted bits is written from cache before the next track in sequence of the bitmap is staged into cache for processing in the same manner.